A Class III Electronic Flight Bag (EFB) device is a relatively new integrated hardware, software, and service solution that enables digital information delivery and management to an aircraft flight deck. The Class III EFB provides an integrated solution for managing important information while the aircraft is in flight or at an airport or airfield. In the United States, Class III EFB devices are regulated by the Federal Aviation Administration (FAA) in accordance with Advisor Circular (AC) 120-76A.
In general, there are three classes of hardware devices and three types of software applications as summarized below:
Hardware Classes:
Class 1—Considered as Portable Electronic Device (PED)
allows connectivity to aircraft for power;
Allows wireless data connectivity;
Class 2—Considered a PED but dockable into a mount on the aircraft during flight
allowed to be connected to a mounting device on an aircraft for power and data connectivity during normal operation;
requires Aircraft Evaluation Group (AEG) and certification, from Aircraft Certification Service (AIR);
is required to go through an administrative control to use in an aircraft.
Class 3—Certified Cockpit Display
considered as installed avionics equipment that requires AIR approval
follows avionics certification standards set forth by the FAA;
certification level depends upon safety hazard analysis.
Software Classes:
Type A: precomposed; fixed presentations; paper format
requires Principal Inspector (PI) approval;
requires Flight Standards District Office operational approval;
requires six-month evaluation period.
Type B—Dynamic, interactive applications
requires PI approval plus Aircraft Evaluation Group (AEG) approval;
requires flight standards operational approval;
requires six-month evaluation period before approval;
requires keeping the aircraft centered on map (but no aircraft symbol);
panning, zooming and other active manipulation allowed;
must be available during all flight phases.
Own-ship Position (i.e. Type C)
AC 120-76A, by itself, may not be used to install own-ship position on a moving map. However, as new guidance is developed, may be used in combination with AC 120-76A to add additional applications.
There are several technical challenges with designing a class III EFB device, that can run all types of software (i.e. Type B, and C with own-ship position). A class III device, which will simultaneously run both Type B software and Type C software sharing the same display screen and keyboard I/O device, is constrained by the following design issues:
FAA Certified Screen Display De-Confliction:
When a lower priority task (typically Type B software) is running in the foreground and has full control of the display screen, and a higher priority task (typically Type C software) is running in the background, the occasion may arise where the higher priority task needs to gain control of the display and the data I/O. For example, if the higher priority task needs to gain control of the display and data entry I/O to provide an urgent message to the pilot, FAA requirements state that the higher priority software must be certified to confirm that it will be able to forcefully gain control of the display hardware and data entry I/O from the lower priority task. Failure to do so may prevent the high priority task from providing urgent warnings to the operator—which would be a safety violation. Presently, to resolve this issue requires an FAA certified approach for interaction between the higher priority task software and the lower priority task software.
Data Separation:
Because of the interaction between different types of software, there will often be certain sharing of common data between the higher priority software application and the lower priority software application. For example, a Type C application could be running a classified task and a Type B application could be concurrently running an unclassified task. Having these applications interacting with each other could give rise to the need for the same security certification for the Type B application. In, other words, the Type B application would need to be able to “de-prioritize” itself to allow the Type C application to take priority over the display and data I/O operations. However, this type of self-prioritizing feature is often not possible to implement with a Type B application since most such applications are commercial “off-the-shelf” (COTS) applications, and the source code for most COTS applications is typically not available to submit for an FAA certification process.
Independent Software Development:
To allow the different applications to run concurrently while sharing the same display and data entry I/O, there must exist an interface control that facilitates the needed display and data I/O sharing that meets FAA requirements for Type B and C applications. However, such a level of interoperability between two otherwise independent software applications, one typically being a COTS software application, is presently not readily available. In practice, it is generally not possible to find independent software applications developed by different entities that are able to run concurrently with the needed level or display and I/O sharing, while implementing the needed level of priority of one application over the other. This issue prevents users from procuring cost effective COTS software (e.g. MS WINDOWS®) to be used on the EFB for managing less critical tasks, while at the same time running a separate, FAA certified software program that manages more flight critical tasks.